Overview

Each LEAF entry in the Groups Register must have a KLVSyntax field that contains at least one value. Note: this statement is not dependent on the value of IsConcrete.

KLVSyntax and Parent Groups

KLVSyntax values are not inherited from a parent Group.

If a Group has IsConcrete set to false then KLVSyntax is interpreted as signalling the intent / expectation that any sub-classes / Groups that inherit from it will use KLVSyntax values within the specified list of values.

It is advisable (but not mandatory) that each Group specifies only KLVSyntax values that are in the list of KLVSyntax values specified by its parent Group (if it has a parent Group). Additional notes on this topic:

  • If choosing (for a new Group) a value of KLVSyntax outside the list specified by the parent Group the author of the new Group (sub-class) should carefully check that this is a sensible choice and will definitely work without problems.
  • For example, the parent Group might have been designed as a Local Set but a sub-class is later defined which is to be encoded as a Pack. The order of Elements within the Group then suddenly becomes important and might need to be given some careful consideration: the parent Group was originally designed as a Local Set and so maybe no consideration was given at all to the order of Elements (because this is irrelevant in Local Set encoding).

KLVSyntax XML data type

KLVSyntax uses the xs:hexBinary XML type – refer to Use of hexBinary for more details.

Use of the value 0x06

SMPTE ST 336 does not permit Byte 6 of a Group UL to have a value of 0x06 for KLV coding – this would suggest that it should not appear as a value for KLVSyntax. However, this is the value of Byte 6 used for Groups / Classes in AAF (which does use SMPTE ULs but does not use KLV coding) and therefore this value does appear in the Groups Register for such Groups.

Current practice is for the value of 0x06 to be included in KLVSyntax if, and only if, the Group is being designed explicitly for use in AAF (note that other practices have sometimes been followed). Not all permitted MXF Groups can necessarily be mapped directly to AAF (for example, some of the Types used by their member Elements might not map directly) and so it is not necessarily safe to assume that a value of 0x06 can be included in the KLVSyntax property of a Group that is being designed for MXF.